Machine Type Communication (MTC) refers to communication between machines over a communication network of a mobile operator. The following several concepts are defined for machine type communication:
MTC Device (MD): A MTC Device refers to a User Equipment dedicated to machine type communication in a communication network, e.g., a remote meter reading device, a video surveillance device, etc. The MTC Device is a special type of communication terminal without human interaction. The 3GPP defines different MTC characteristics, e.g., low mobility, time controlled, etc., for different MD characteristics.
MTC server: A MTC server refers to a device in communication with the MTC device over the communication network and is equivalent to a server, e.g., a server of an intelligent meter reading system, a server of an intelligent public transportation system, etc.
MTC user: A MTC user uses a service provided by the MTC server.
FIG. 1 is a schematic architectural diagram of machine type communication illustrating an architectural diagram of communication between an MD, an MTC server and a 3GPP system. In machine type communication, the 3rd Generation Partnership Project (3GPP) system provides transmission and communication services, e.g., a bearer service, an IP Multimedia System (IMS), short message service, etc., for communication between the MD and the MTC server, and traditional communication modes are optimized to some extent in view of characteristics of machine type communication.
Since the machine type communication device typically operates in an “unmanned” status and may be deployed in some highly risky area (susceptible to theft or breakage), the 3GPP proposes a demand for MTC monitoring (where the network monitors the MD for a specific event and reports the event to the MTC server or the MTC user upon detection thereof) in order to secure the use of such a kind of MD. The demand for MTC monitoring defined in 3GPP TS 22.368 is particularly as follows:
1. A network operator shall be able to detect the following events:
1) The device has a behavior in no compliance with an activated MTC characteristic (for example, the location of an MD with the characteristic of low mobility is updated frequently);
2) An access point is changed (e.g., an access outside a restricted area);
3) A match relationship between the terminal device and a Universal Integrated Circuit Card (UICC) is changed; and
4) A connection is lost.
2. The MTC user shall define which of the foregoing events will be monitored.
3. The network shall be able to perform the following operations upon occurrence of an monitoring event:
1) An alarm message is provided to the MTC user or the MTC server; and
2) A service provided to the MD is restricted (for example, an allocated resource is reduced, etc.);
4. The operation(s) subsequent to occurrence of the event shall be defined by the MTC user; and
5. The MD shall be able to transmit a message to the MTC server to indicate an event for which a detection method is beyond the reach of the 3GPP.
Detection and reporting methods are proposed in 3GPP TS 23.888 respectively for the foregoing events. An event to be detected and a relevant rule (e.g., an allowed location area) are configured and also an operation to be performed by the network (for example, the MD is detached from the network) upon occurrence of the configured event can be configured in subscription data of the MD as a basic of detection and reporting.
TS 23.888 proposes a method of detecting an event of “change in point of attachment” to be primarily performed by a core network control node which is a Mobility Management Entity (MME) in an Long Term Evolution (LTE) system and a Serving GPRS Support Node (SGSN) or a Mobile Switching Center (MSC) in a Universal Mobile Telecommunications System (UMTS).
TABLE 6.10.2-1SGSN/MME Based DetectionMonitoring an EventProceduresMonitoring the1> The SGSN/MME asks for the MTC Device IMEI (e.g. Identity procedure).association between2> The SGSN/MME checks whether the IMEI provided by the device is the samethe MTC Device andas the configured IMEI.the UICC3> If not, then the SGSN/MME shall trigger reporting.Monitoring the1> The SGSN/MME checks whether the MTC Device behavior is aligned with thealignment of theactivated MTC features for the device.MTC feature2> If not (e.g. the MTC Device with a low mobility feature performs an RAU/TAUor handover procedure frequently), then the SGSN/MME shall trigger reporting.Monitoring a change1> The SGSN/MME checks whether there is a change of point of attachment.in the point of2> If so, then the SGSN/MME shall trigger reporting.attachmentMonitoring a loss of1> The SGSN/MME checks whether the MTC Device is offline.connectivity2> If so, then the SGSN/MME shall trigger reporting.
FIG. 2 illustrates a procedure of MME/SGSN based detection and reporting in the prior art, where a Core Network (CN) node is an MME in an LTE system and an SGSN or an MSC in a UMTS system. A user subscription data server is an Home Subscriber Server (HSS) in an Evolved Packet System (EPS) and a Home Location Register (HLR) in a UMTS system, and an event to be monitored (a change in point of attachment as an example) has been configured in subscription data, and then the flow can include:
Step 201: An MD initiates an Attach Request for an access to the network.
Step 202: The CN node transmits a Location Update Request to the user subscription data server.
Step 203: The user subscription data server returns to the CN node a Location Update Response including the subscription data of the MD, which includes a definition of the monitoring event, a default operation upon occurrence of the event, etc.
Step 204: The CN node returns an Attachment Accept to the MD, and the MD accesses the network.
Step 205: The CN node monitors in response to the instruction contained in the subscription data.
Step 206: The CN node reports the event to an MTC server or an MTC user upon occurrence of the event.
Step 207: If the MTC server or the MTC user is specified to instruct the CN node regarding a subsequent action, the MTC server/the MTC user returns an action instruction. If the MTC server/user returns no instruction, then the CN node performs the default action in the subscription data.
Step 208: The CN node performs the action, for example, detaching the MD from the network, etc.
In the demand for MTC monitoring, existing detection of “a change in point of attachment” is generally performed by the network, e.g., SGSN/MME based detection. This method has the following drawbacks:
1) There is some impact on the HSS/HLR: the event information is configured in the subscription data of the MD, and the data in the HSS/HLR has to be synchronized rapidly upon occurrence of a change of event (for example, the allowed access area is updated, etc.). In addition to this, an interface between the MTC server/user and the HSS/HLR has to be further added and a relevant operation flow has to be defined. However the data in the HSS/HLR as a subscription data server shall be altered as infrequently as possible and also interfaces and interaction between the other nodes and the HSS/HLR in the network shall be reduced as many and much as possible to thereby ensure stability of the HSS/HLR; and
2) The granularity of network-based method of detecting a “change of attachment” is not fine-grained. When the terminal enters an idle mode, the core network can know information of the location of the terminal only at the granularity of a location area (a list of routing areas or tracking areas) in the prior art, and the network can not perform the function of detecting a “change of attachment” in the existing method if the terminal is allowed to attach to a small area, for example one or more cells.